עקרונות שפות תכנות, סמסטר ב' 2016 תרגול 7: הסקת טיפוסים סטטית. Axiomatic Type Inference

Size: px
Start display at page:

Download "עקרונות שפות תכנות, סמסטר ב' 2016 תרגול 7: הסקת טיפוסים סטטית. Axiomatic Type Inference"

Transcription

1 עקרונות שפות תכנות, סמסטר ב' 2016 תרגול 7: הסקת טיפוסים סטטית 1. Axiomatic type inference 2. Type inference using type constraints נושאי התרגול: Axiomatic Type Inference Definition (seen in class): A Type-substitution is a mapping, s, from a finite set of type-variables to a finite set of type-expressions, such that for every type-variable T, s(t) does not include T. A type-binding is a pair <T,s(T)> such that T = s(t). Type-s are written using set notation, for example: {T1 = Number, T2 = [Number -> T3]} {T1 = Number, T2 = [[Number -> T3]->T2]}, is this legal? Question 1 A typing statement is a true/false formula that states a judgment about the type of a language expression, given a type environment. It has the notation: Tenv - e:t, which reads: under the type-environment Tenv, the expression e has type T. E.g., {x:number} - (+ 3 x):number states that under the assumption that the type of x is Number, the type of (+ 3 x) is Number. For the typing statement below, note whether they are true or false: Typing statement true/false? {f:[number->t1]} - (f 7): T1 {y:number, f:[t1->t1]} - (f x):t1 {x:number} - x: Boolean {x:boolean, y:number} - x: Boolean Question 2 A typing-statement is based on assumptions in a given type-environment. The less assumptions are involved, the stronger is the statement. In order to end up with the strongest statement, we follow a simple heuristic rule: always pick a minimal type environment (or: always infer the strongest statement possible). For each pair of statements below, which statement is stronger? -1-

2 {foo: [T1->T2]} - 5:N {} - 5:N {x:n} - (+ x 3):N {y:n,x:n} - (+ x 3):N {} - (lambda (x)(+ x 3)):[N->N] {y:n} - (lambda (x)(+ x y)):[n->n] Note: A typing statement has to be true in order to determine its strength. Definitions (seen in class): An application of a type-substitution s to a type-expression TE, denoted by TE s, is a consistent replacement of type-variables T in TE by their mapped type-expressions s(t). For example: Well-typeness (partial definition): [[T1->T2]->T2] {T1=Boolean, T2=[T3->T3]} = [[Boolean->[T3->T3]] -> [T3->T3]] An expression, e, is well typed if Type-derivation(e) does not fail, i.e: Type-derivation(e)= TS, derivation, where Type-derivation is the set of typing statements obtained during the type inference for e. e has type t if it is well typed, and Type-derivation(e)= { } - e:t,derivation. Instantiation of typing statements: An instance of a typing statements TS is a typing statement TS that results from the application of a type-substitution s to all type expressions in TS. The instantiation is denoted by TS = TS s. Question 3 A unifier of type expressions TE1, TE2 is a type substitution s such that TE1 s = TE2 s (the type expressions should not include common type variables). The most general unifier (MGU), is a unifier such that any other unifier is an instance of it. All other unifiers are obtained from it by application of additional substitutions. Find the MGU for the following pairs of type-environments: s {x: T1}, {x: N} {x: T1, y: [T1->T2]}, {x: Number, y: [T3->T4]} {x: T1, y: [T1 -> T2]}, {x: [T3->T4], y: [T5->Number]} {x: T1, y: [T1->T2]}, {x: Number, y: [Symbol -> T3]} MGU {T1=N} (a non-mgu unifier: {T1=N, T2=B}) {T1=Number, T3=Number, T4=T2} {T1=[T3->T4], T5=[T3->T4], T2=Number} No unifier -2-

3 Question 4 Derive the type of the following expression: (lambda (x) (+ 7 x)) Step 1 Renaming: (lambda (x1) (+ 7 x1)) Step 2 Initializing derived-ts-pool: derived-ts-pool = { } Step 3 - Typing leaf expressions: The leaves are +, 7, x1. Instantiating the Number, Variable and the Primitive procedure axioms: (lambda (x1) (+ 7 x1)) (+ 7 x1) + 7 x1 a. Typing the expression 7: Typing axiom Number: For every type environment _Tenv and number _n: _Tenv - _n: Number Replacing the meta-variables _Tenv and _n with { } and 7, respectively, yields: (1) { } - 7 : Number derived-ts-pool= { (1) } b. Typing the expression + : Typing axiom Primitive +: For every type environment _Tenv: _Tenv - +:[N* *N-> N] Replacing the meta-variable _Tenv with { } yields: (2) { } - + : [N * * N -> N] derived-ts-pool = {(1), (2)} c. Typing the expression x1: Typing axiom Variable: For every type environment _Tenv and variable _v: _Tenv - _v: _Tenv(_v) Replacing _Tenv with {x1:t} and _v with the expression-variable x1, yields: (3) {x1:t} - x1:t derived-ts-pool = {(1), (2), (3)} Note: the Variable axiom uses a type-environment with an assumption to the typed variable. Since no type is declared for x, its type is just a type variable. Step 4 - Typing non-leaf expressions: a. Typing the expression (+ 7 x1): Typing Rule Application: For every: type environment _Tenv, expressions _f, _e1, _en, n>=0, and type expressions _S1,, _Sn, _S: If _Tenv - _f:[_s1* * _Sn -> _S], _Tenv - _e1:_s1,, _Tenv - _en:_sn Then _Tenv - (_f _e1 _en):_s -3-

4 Replacing _f, _e1 and _e2 with +, 7 and x1, respectively, yields an instance of that rule: For every: type environment _Tenv, expressions +, 7, x1, and type expressions _S1,_S2, _S: If _Tenv - +:[_S1*_S2 -> _S], _Tenv - 7:_S1, _Tenv - x1:_s2 Then _Tenv - (+ 7 x1):_s It remains to find _Tenv and a type-substitution, s, so that the condition of the rule holds. In other words, we seek for _Tenv and s such that: (_Tenv - +:[_S1*_S2 -> _S]) s derived-ts-pool s, (_Tenv - 7:_S1) s derived-ts-pool s, (_Tenv - x1:_s2) s derived-ts-pool s, where derived-ts-pool = { (1) { } - 7:N, (2) { } - +:[N * N -> N], (3) {x1:t} - x1:t } with _Tenv = {}, s = (_S1 = N, _S2 = N, _S = N) we get ({} - +:[_S1*_S2 -> _S]) s = (2) with _Tenv = {}, s = (_S1 = N) we get ({} - 7:_S1) s = (1) with _Tenv = {x1:t}, s = (_S2 = T), we get ({x1:t} - x1:_s2) s = (3) The problem: the condition of the rule uses the same _Tenv in all statements. We solve this by applying the Monotonicity rule to (1) and (2) with _Tenv ={x:t} and adding to derived-ts-pool: (1 ) {x1:t} - 7:N (2 ) {x1:t} - +:N * N -> N The instance of the rule now becomes: For every: type environment {x1:t}, expressions +, 7, x1, and type expressions _S1,_S2, _S: If {x1:t} - +:[_S1*_S2 -> _S], {x1:t} - 7:_S1, {x1:t} - x1:_s2 Then {x1:t} - (+ 7 x1):_s With type-substitution s = (_S1 = N, _S2 = N, _S = N, T = _S2}, the condition holds and the result is the conclusion of the rule: (4) {x:n} - (+ x 7): N derived-ts-pool={(1) (1 ) (2) (2 ) (3) (4)} -4-

5 b. Typing the expression (lambda (x1) (+ 7 x1)) : Typing rule Procedure: For every: type environment Tenv variables _x1,..., _xn, n >= 0 expressions _b1,..., _bm, m >= 1, and type expressions _S1,...,_Sn, _U1,...,_Um : If _Tenv {_x1:_s1,...,_xn:_sn } - _bi:_ui for all i=1 m Then _Tenv - (lambda (_x1... _x_n ) _b1... _bm) : [_S1*...*_Sn -> _Um] Replacing _Tenv with { }, _x1 with x1 and _b1 with (+ 7 x1), yields an instance of that rule: For every: type environment {} variables x1 expressions (+ 7 x1), and type expressions _S1, _U1: If { } {x1:_s1} - (+ 7 x1):_u1 Then { } - (lambda (x1) (+ 7 x1)) : [_S1 -> _Um] Now, with type-substitution s = (_S1 = N, _U1 = N), the condition of the rule holds and the result is the conclusion of the rule: (5) { } -(lambda(x1) (+ x1 7)): [N -> N] derived-ts-pool = {(1) (1 ) (2) (2 ) (3) (4) (5)} Finally, the output of the algorithm is: {{ } -(lambda(x) (+ x 7)): [N->N], derived-ts-pool}. By the definition, (lambda(x) (+ 7 x)) is well typed and its type is [N->N]. Question 5: Derive the type for the following expression: (lambda (x) (+ y (- x 1))) Step 1 Renaming: (lambda (x1) (+ y1 (- x1 1))) Step 2 Initializing derived-ts-pool: derived-ts-pool = { } Step 3 - Typing leaf expressions: The leaves are +, y, -, x1, 1. Instantiating the Number, Variable and the Primitive procedure axioms, yields: (1) { } - +: [N * N -> N] (2) {y1: T1} - y1: T1 (3) { } - -: [N * N -> N] (4) {x1: T2} - x1: T2 (5) { } - 1: N pool = {(1), (2), (3), (4), (5)} (lambda (x1)(+ y1 (- x1 1))) (+ y (- x1 1)) + y (- x1 1) - x1 1-5-

6 Step 4 - Typing non-leaf expressions: a. Typing the expression (- x1 1): In typing rule Application, replacing _f, _e1 and _e2 for -, x1 and 1, respectively, yields: For every: type environment _Tenv, expressions -, x1, 1, and type expressions _S1,_S2, _S: If _Tenv - -:[_S1*_S2 -> _S], _Tenv - x1:_s1, _Tenv - 1:_S2 Then _Tenv - (- x1 1):_S Using the monotonicity rule, we add the following statements to derived-ts-pool: (3 ) {x1:t2} - -: [N * N -> N] (5 ) {x1:t2} - 1: N With _Tenv={x1:T2} and type-substitution s = (_S1 = N, _S2 = N, _S = N, T2=_S2) the condition of the rule holds and the result is the conclusion of the rule: (6) {x1: N} - (- x1 1) : N pool = {(1) (2) (3) (4) (5) (3 ) (5 ) (6)} b. Typing the expression (+ y (- x1 1)): In typing rule Application, replacing _f, _e1 and _e2 for +, y and (- x1 1), respectively, yields: For every: type environment Tenv, expressions +, y, (- x1 1), and type expressions _S1,_S2, _S: If _Tenv - +:[_S1*_S2 -> _S], _Tenv - y:_s1, _Tenv - (- x1 1):_S2 Then _Tenv - (+ y (- x1 1)):_S Using the monotonicity rule, we add the following statements to derived-ts-pool: (1 ) {y: T1, x1: T2} - +: N * N -> N (6 ) {y: T1, x1: T2} - (- x1 1):N (2 ) {y: T1, x1: T2} - y: N Now, with type-substitution s = (_S1 = N, _S2 = N, _S = N, T1 = _S1, T2=_S2), the condition of the rule holds and the result is the conclusion: (7) {y: N, x1: N} - (+ y (- x1 1)): N pool = {(1) (1 ) (2) (2 ) (3) (3 ) (4) (5) (5 ) (6) (6 ) (7)} -6-

7 c. Typing the expression (lambda(x1) (+ y (- x1 1))) : In typing rule Procedure, replacing _Tenv with {y:n}, _x1 with x1 and _b1 with (+ y (- x1 1)) yields: For every: type environment {y:n}, variable x1, expression (+ y (- x1 1)), type expressions _S1, _U1: If {y:n} {x1:_s1} - (+ y (- x1 1)):_U1 Then {y:n} -(lambda(x1)(+ y (- x1 1))):[_S1 -> _U1] With type substitution s = (_S1 = N, _U1 = N), the condition holds and the conclusion is: (8) {y: N} -(lambda (x1)(+ y (- x 1)):[N -> N] pool = {(1) (1 ) (2) (2 ) (3) (3 ) (4) (5) (5 ) (6) (6 ) (7) (8)} Output: {{y: N} -(lambda (x1)(+ y (- x 1)):[N -> N], pool}. Note: The type environment, {y: Number}, in the output statement is not empty. From the definition of well-typeness, the expression is well typed. However, we cannot associate a type with the expression. Question: Could we associate a type with the expression if we added expression (define y 5) before it? Question 6 (optional): Derive the type of the expression (define foo (lambda (x) (foo (+ x 1)))) Step 1 Renaming: (define foo (lambda (x1) (foo (+ x1 1)))) Step 2 Initializing derived-ts-pool: pool = { } Step 3 - Typing leaf expressions: The leaves are +, foo, x1, 1. Instantiating the Number, Variable and the Primitive procedure axioms, yields: (1) {} - 1: Number (2) {} - +: [N * N -> N] (3) {x1:t1} - x1: T1 (4) {foo:t2} - foo: T2 pool = {(1), (2), (3), (4)} Step 4 - Typing non-leaf expressions We skip a few steps forward to evaluate the type for (lambda (x1) (foo (+ x1 1))), where pool = { (1) {} - 1: N, (1') {x1: N} - 1: N, (2) {} - +: [N * N -> N], (2') {x1: N} - +: [N * N -> N], -7-

8 (3) {x1: T1} - x1: T1, (4) {foo: T2} - foo: T2, (5) {x1: N} - (+ x1 1): N, (6) {x1: N, foo: [N -> T3]} - foo: [N -> T3], (5') {x1: N, foo: [N -> T3]} - (+ x1 1): N, (7) {x1: N, foo: [N -> T3]} - (foo (+ x1 1)): T3} a. Typing the expression (lambda (x1) (foo (+ x1 1))): In typing rule Procedure, replacing _Tenv with {foo: [N -> T3]}, _x1 with x1 and _b1 with (foo (+ x1 1)), yields: For every: type environment {foo: [N -> T3]}, variables x1 expressions (foo (+ x1 1)), and type expressions _S1, _U1: If {foo: [N -> T3]} {x1:_s1} - (foo (+ x1 1)): _U1 Then {foo: [N -> T3]} - (lambda(x1) (foo (+ x1 1))):[_S1-> _U1] With type substitution s = (_S1 = N, _U1 = T3), the condition holds, and the results is: (8) {foo: [N ->T3]} - (lambda(x1)(foo (+ x1 1))): [N -> T3] pool = {(1),, (7) (8)} b. Typing the expression (define foo (lambda (x) (foo (+ x 1)))): In typing rule Recursive-definition, replacing _f with foo and _e with (lambda (x) (foo (+ x 1))) yields: For every: recursive-definition expression (define foo (lambda (x) (foo (+ x 1)))) and type expression _S: If { foo:_s } - (lambda (x) (foo (+ x 1))):_S, Then { } - (define foo (lambda (x) (foo (+ x 1)))):Void, and { } - foo:_s Restriction: No repeated variable definitions. With type substitution s = (_S = [Number->T3]), the condition holds and the result is: (9) { } - (define foo (lambda (x)(foo (+ x 1)))):Void, and (10) { } - foo: [Number -> T3] pool = {(1),..., (7), (8), (9), (10)} Output: {(9), pool}. The expression well typed and has type void. Question 7 (optional) When we derive the expression: ( (lambda (f) (+ (f 'a) (f 5))) (lambda (x) 3) ), the axiomatic type inference process fails for the expression (+ (f 'a) (f 5)). However, Racket evaluates the expression with no troubles. How is that possible? -8-

9 Type inference using type constraints 1. Rename bound variables. 2. Assign type variables to all sub-expressions. 3. Construct type equations. 4. Solve the equations. Question 1 Typing the expression ((lambda (f x) (f x)) sqrt 4): Stage I: Rename bound variables. No other reference of variables f and x so no renaming is needed. Stage II: Assign type variables for every sub expression: Variable ((lambda (f x) (f x)) sqrt 4) T0 (lambda (f x) (f x)) T1 (f x) T2 f Tf x Tx sqrt Tsqrt 4 Tnum4 Stage III: Construct type equations. The equations for the sub-expressions are: ((lambda (f x) (f x)) sqrt 4) T1 = [Tsqrt * Tnum4 -> T0] (lambda (f x) (f x)) T1 = [Tf * Tx -> T2] (f x) Tf = [Tx -> T2] The equations for the primitives are: sqrt Tsqrt = [Number -> Number] 4 Tnum4 = Number Stage IV: Solve the equations. 1. T1 = [Tsqrt * Tnum4 -> T0] {} 2. T1 = [Tf * Tx -> T2] 3. Tf = [Tx -> T2] 4. Tsqrt = [Number -> Number] 5. Tnum4 = Number -9-

10 Step 1: (T1 = [Tsqrt * Tnum4-> T0]) = (T1 = [Tsqrt * Tnum4-> T0]) and is a type-sub. = (T1 = [Tsqrt * Tnum4-> T0]). 2. T1 = [Tf * Tx -> T2] {T1 := [Tsqrt * Tnum4 -> T0]} 3. Tf = [Tx -> T2] 4. Tsqrt = [Number -> Number] 5. Tnum4 = Number Step 2: T1 = [Tf * Tx -> T2] = ([Tsqrt * Tnum4 -> T0] = [Tf * Tx -> T2]), not typesub. Because both sides of the equation are composite we split it into three equations and remove equation Tf = [Tx -> T2] {T1 := [Tsqrt * Tnum4 -> T0]} 4. Tsqrt = [Number -> Number] 5. Tnum4 = Number 6. Tf = Tsqrt 7. Tx = Tnum4 (or Tnum4 = Tx) Step 3: (Tf = [Tx -> T2]) = (Tf = [Tx -> T2]). = (Tf = [Tx -> T2]). 4. Tsqrt = [Number -> Number] {T1 := [Tsqrt * Tnum4 -> T0] 5. Tnum4 = Number Tf := [Tx -> T2]} 6. Tf = Tsqrt 7. Tx = Tnum4 Step 4: (Tsqrt = [Number -> Number]) = (Tsqrt = [Number -> Number]). = (Tsqrt = [Number -> Number]). 5. Tnum4 = Number {T1 := [[Number -> Number] * Tnum4-> T0] 6. Tf = Tsqrt Tf := [Tx -> T2] 7. Tx = Tnum4 Tsqrt := [Number -> Number]} -10-

11 Step 5: (Tnum4 =Number) = (Tnum4 =Number), is a type-sub. = (Tnum4 =Number). 6. Tf = Tsqrt {T1 := [[Number -> Number]* Number -> T0] 7. Tx = Tnum4 Tf := [Tx -> T2] Tsqrt := [Number -> Number] Tnum4 := Number} Step 6: (Tf = Tsqrt) = ([Tx -> T2]=[Number -> Number]), not a sub-type. We split the equation into two equations Tx = Number and T2 = Number and remove equation Tx = Tnum4 {T1 := [[Number -> Number]* Number -> T0] 9. Tx = Number Tf := [Tx -> T2] Tsqrt := [Number -> Number] 10. T2 = Number Tnum4 := Number} Step 7: (Tx = Tnum4) = ([Tx -> Number]), type-sub. = ([Tx -> Number]). {T1 := [[Number -> Number] * Number -> T0] 9. Tx = Number Tf := [Number -> T2] 10. T2 = Number Tsqrt := [Number -> Number] Tnum4 := Number Tx := Number} Step 8: (T2 = T0) = (T2 = T0), type-sub. = (T2 = T0). 9. Tx = Number {T1 := [[Number -> Number] * Number -> T0] 10. T2 = Number Tf := [Number -> T0] Tsqrt := [Number -> Number] Tnum4 := Number Tx := Number T2 := T0} -11-

12 Step 9: (Tx = Number) = (Number = Number) always true. Step 10: 10. T2 = Number {T1 := [[Number -> Number] * Number -> T0] Tf := [Number -> T0] Tsqrt := [Number -> Number] Tnum4 := Number Tx := Number T2 := T0} (T2 = Number) = (T0 = Number), type-sub. = (T0 = Number). {T1 := [[Number -> Number] * Number -> Number] Tf := [Number -> Number] Tsqrt := [Number -> Number] Tnum4 := Number Tx := Number T2 := Number T0 = Number} The type inference succeeds, meaning that the expression is well typed. Because there are no free variables, the inferred type of T0 is: Number. -12-

13 Question 2: Extending the typing mechanism for if expressions: Recall the typing rule for if expressions shown in the axiomatic typing system: Typing rule If : For every: type environment _Tenv, expressions _e1, _e2, _e3, and type expressions _S1, _S2: If _Tenv - _e1:_s1, _Tenv - _e2:_s2, _Tenv - _e3:_s2 Then _Tenv - (if _e1 _e2 _e3):_s2 First thing we notice from the rule is that the consequence expression (_c) and the alternative expression (_a) have the same type. Given the first observation, the second thing we notice is that the type of the if expression is the type of the consequence expression. Given the two observation we can add the following equations: (if _p _c _a) T_c = T_a Tif = T_c Questions: 1) If both consequence and alternative expressions had different types could we type the if expression? 2) Do we need to add an equation for _p? Example: type the expression (if #t (+ 1 2) 3) Stage I: Rename bound variables: No reference of variables so no renaming is needed. Stage II: Assign type variables for every sub expression: Variable (if #t (+ 1 2) 3) T0 (+ 1 2) T1 + T+ #t T#t 1 Tnum1 2 Tnum2 3 Tnum3 Stage III: Construct type equations. The equations for the sub-expressions are: (if #t (+ 1 2) 3) T1 = Tnum3 T0 = T1 (+ 1 2) T+ = [Tnum1 * Tnum2 -> T1] -13-

14 The equations for the primitives are: + T+ = [Number * Number -> Number] #t T#t = Boolean 1 Tnum1 = Number 2 Tnum2 = Number 3 Tnum3 = Number Stage IV: Solve the equations: 1. T1 = Tnum3 {} 2. T0 = T1 3. T+ = [Tnum1 * Tnum2 -> T1] 4. T+ = [Number * Number -> Number] 5. T#t = Boolean 6. Tnum1 = Number 7. Tnum2 = Number 8. Tnum3 = Number Step 1: (T1 = Tnum3) = (T1 = Tnum3), type-sub. = (T1 = Tnum3). 2. T0 = T1 { T1 := Tnum3 } 3. T+ = [Tnum1 * Tnum2 -> T1] 4. T+ = [Number * Number -> Number] 5. T#t = Boolean 6. Tnum1 = Number 7. Tnum2 = Number 8. Tnum3 = Number Step 2: (T0 = T1) = (T0 = Tnum3), type-sub. = (T0 = Tnum3). 3. T+ = [Tnum1 * Tnum2 -> T1] { T1 := Tnum3, 4. T+ = [Number * Number -> Number] T0 := Tnum3 } 5. T#t = Boolean 6. Tnum1 = Number 7. Tnum2 = Number 8. Tnum3 = Number -14-

15 Step 3: (T+ = [Tnum1 * Tnum2 -> T1]) = (T+ = [Tnum1 * Tnum2 -> Tnum3]), type-sub. = (T+ = [Tnum1 * Tnum2 -> Tnum3]). 4. T+ = [Number * Number -> Number] { T1 := Tnum3, 5. T#t = Boolean T0 := Tnum3, 6. Tnum1 = Number T+ := [Tnum1 * Tnum2 -> Tnum3]} 7. Tnum2 = Number 8. Tnum3 = Number Step 4: (T+ = [Number * Number -> Number]) = ([Tnum1 * Tnum2 -> Tnum3] = [Number * Number -> Number]), not a type-sub. We split the equation to Tnum1 = Number, Tnum2 = Number and Tnum3 = Number, and add them to the equations. Since they already exists, we only need to remove equation T#t = Boolean { T1 := Tnum3, 6. Tnum1 = Number T0 := Tnum3, 7. Tnum2 = Number T+ := [Tnum1 * Tnum2 -> Tnum3]} 8. Tnum3 = Number Skipping the trivial steps, we get: { T1 := Number, T0 := Number, T#t := Boolean, Tnum1 := Number, Tnum2 := Number, Tnum3 := Number, T+ := [Number * Number -> Number]} The type inference succeeds, meaning that the expression is well typed. Because there are no free variables, the inferred type of T0 is: Number. -15-

16 Question 3 (optional) Typing the application ((lambda (f x) (f x)) 4 sqrt): Stage I: Rename bound variables. No other reference of variables f and x so no renaming is needed. Stage II: Assign type variables for every sub expression and primitives: Variable ((lambda (f x) (f x)) 4 sqrt) T0 (lambda (f x) (f x)) T1 (f x) T2 f Tf x Tx 4 Tnum4 sqrt Tsqrt Stage III: Construct type equations. The equations for the sub-expressions are: ((lambda(f x) (f x)) 4 sqrt) T1 = [Tnum4 * Tsqrt -> T0] (lambda(f x) (f x)) T1 = [Tf * Tx -> T2] (f x) Tf = [Tx -> T2] The equations for the primitives are: 4 Tnum4 = Number sqrt Tsqrt = [Number -> Number] Stage IV: Solve the equations. 1. T1 = [Tnum4 * Tsqrt -> T0] {} 2. T1 = [Tf * Tx -> T2] 3. Tf = [Tx -> T2] 4. Tnum4 = Number 5. Tsqrt = [Number -> Number] Step 1: (T1 = [Tnum4 * Tsqrt -> T0]) = (T1 = [Tnum4 * Tsqrt -> T0]), type-sub. = (T1 = [Tnum4 * Tsqrt -> T0]). 2. T1 = [Tf * Tx -> T2] {T1 := [Tnum4 * Tsqrt -> T0]} 3. Tf = [Tx -> T2] 4. Tnum4 = Number 5. Tsqrt = [Number -> Number] -16-

17 Step 2: (T1 = [Tf * Tx -> T2]) = ([Tf * Tx -> T2] = [Tnum4 * Tsqrt -> T0]), not a type-sub. We split the equation to Tf = Tnum4, Tx = Tsqrt, T2 = T0, add them to the equations and remove equation Tf = [Tx -> T2] {T1 := [Tnum4 * Tsqrt -> T0]} 4. Tnum4 = Number 5. Tsqrt = [Number -> Number] 6. Tf = Tnum4 7. Tx = Tsqrt Step 3: (Tf = [Tx -> T2]) = (Tf = [Tx -> T2]), type-sub. = (Tf = [Tx -> T2]). 4. Tnum4 = Number {T1 := [Tnum4 * Tsqrt -> T0] 5. Tsqrt = [Number -> Number] Tf = [Tx -> T2]} 6. Tf = Tnum4 7. Tx = Tsqrt Step 4: (Tnum4 = Number) = (Tnum4 = Number), type-sub. = (Tnum4 = Number). 5. Tsqrt = [Number -> Number] {T1 :=[Number * Tsqrt -> T0] 6. Tf = Tnum4 Tf = [Tx -> T2] 7. Tx = Tsqrt Tnum4 = Number} Step 5: (Tsqrt = [Number -> Number]) = (Tsqrt = [Number -> Number]), type-sub. = (Tsqrt = [Number -> Number]). 6. Tf = Tnum4 {T1 :=[Number * [Number- > Number] -> T0] 7. Tx = Tsqrt Tf := [Tx -> T2] Tnum4 := Number Tsqrt := [Number->Number]} Step 6: (Tf = Tnum4) = ([Tx -> T2] = Number), We get the conflicting equation [Tx -> T2] = Number and we can say that the expression is not well typed. -17-

Principles of Programming Languages

Principles of Programming Languages Principles of Programming Languages Slides by Dana Fisman based on book by Mira Balaban and lecuture notes by Michael Elhadad Lesson 15 Type Inference Collaboration and Management Dana Fisman www.cs.bgu.ac.il/~ppl172

More information

Principles of Programming Languages

Principles of Programming Languages Principles of Programming Languages Lesson 14 Type Checking Collaboration and Management Dana Fisman www.cs.bgu.ac.il/~ppl172 1 Type Checking We return to the issue of type safety we discussed informally,

More information

עקרונות שפות תכנות 2018 תרגול 8 Type Inference System

עקרונות שפות תכנות 2018 תרגול 8 Type Inference System עקרונות שפות תכנות 2018 תרגול 8 Type Inference System Type Inference System The Type Inference System is a TypeScript Implementation of the algorithm for Type Checking and Inference using Type Equations.

More information

Typed Racket: Racket with Static Types

Typed Racket: Racket with Static Types Typed Racket: Racket with Static Types Version 5.0.2 Sam Tobin-Hochstadt November 6, 2010 Typed Racket is a family of languages, each of which enforce that programs written in the language obey a type

More information

Module 6. Knowledge Representation and Logic (First Order Logic) Version 2 CSE IIT, Kharagpur

Module 6. Knowledge Representation and Logic (First Order Logic) Version 2 CSE IIT, Kharagpur Module 6 Knowledge Representation and Logic (First Order Logic) 6.1 Instructional Objective Students should understand the advantages of first order logic as a knowledge representation language Students

More information

CMSC 330: Organization of Programming Languages

CMSC 330: Organization of Programming Languages CMSC 330: Organization of Programming Languages Operational Semantics CMSC 330 Summer 2018 1 Formal Semantics of a Prog. Lang. Mathematical description of the meaning of programs written in that language

More information

The Typed Racket Guide

The Typed Racket Guide The Typed Racket Guide Version 5.3.6 Sam Tobin-Hochstadt and Vincent St-Amour August 9, 2013 Typed Racket is a family of languages, each of which enforce

More information

Programming Languages Third Edition

Programming Languages Third Edition Programming Languages Third Edition Chapter 12 Formal Semantics Objectives Become familiar with a sample small language for the purpose of semantic specification Understand operational semantics Understand

More information

Formal Semantics of Programming Languages

Formal Semantics of Programming Languages Formal Semantics of Programming Languages Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson http://www.daimi.au.dk/~bra8130/wiley_book/wiley.html Benefits of formal

More information

Module 6. Knowledge Representation and Logic (First Order Logic) Version 2 CSE IIT, Kharagpur

Module 6. Knowledge Representation and Logic (First Order Logic) Version 2 CSE IIT, Kharagpur Module 6 Knowledge Representation and Logic (First Order Logic) Lesson 15 Inference in FOL - I 6.2.8 Resolution We have introduced the inference rule Modus Ponens. Now we introduce another inference rule

More information

Lecture #23: Conversion and Type Inference

Lecture #23: Conversion and Type Inference Lecture #23: Conversion and Type Inference Administrivia. Due date for Project #2 moved to midnight tonight. Midterm mean 20, median 21 (my expectation: 17.5). Last modified: Fri Oct 20 10:46:40 2006 CS164:

More information

Formal Semantics of Programming Languages

Formal Semantics of Programming Languages Formal Semantics of Programming Languages Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson http://www.daimi.au.dk/~bra8130/wiley_book/wiley.html Benefits of formal

More information

If a program is well-typed, then a type can be inferred. For example, consider the program

If a program is well-typed, then a type can be inferred. For example, consider the program CS 6110 S18 Lecture 24 Type Inference and Unification 1 Type Inference Type inference refers to the process of determining the appropriate types for expressions based on how they are used. For example,

More information

Conversion vs. Subtyping. Lecture #23: Conversion and Type Inference. Integer Conversions. Conversions: Implicit vs. Explicit. Object x = "Hello";

Conversion vs. Subtyping. Lecture #23: Conversion and Type Inference. Integer Conversions. Conversions: Implicit vs. Explicit. Object x = Hello; Lecture #23: Conversion and Type Inference Administrivia. Due date for Project #2 moved to midnight tonight. Midterm mean 20, median 21 (my expectation: 17.5). In Java, this is legal: Object x = "Hello";

More information

Z Notation. June 21, 2018

Z Notation. June 21, 2018 Z Notation June 21, 2018 1 Definitions There are many different ways to introduce an object in a Z specification: declarations, abbreviations, axiomatic definitions, and free types. Keep in mind that the

More information

Chapter 22: Type Reconstruction (Type Inference)

Chapter 22: Type Reconstruction (Type Inference) Chapter 22: Type Reconstruction (Type Inference) Calculating a Principal Type for a Term Constraint based Typing Unification and Principle Types Extension with let-polymorphism Type Variables and Type

More information

Lecture #13: Type Inference and Unification. Typing In the Language ML. Type Inference. Doing Type Inference

Lecture #13: Type Inference and Unification. Typing In the Language ML. Type Inference. Doing Type Inference Lecture #13: Type Inference and Unification Typing In the Language ML Examples from the language ML: fun map f [] = [] map f (a :: y) = (f a) :: (map f y) fun reduce f init [] = init reduce f init (a ::

More information

Principles of Programming Languages, Spring 2016 Assignment 5 Logic Programming

Principles of Programming Languages, Spring 2016 Assignment 5 Logic Programming Principles of Programming Languages, Spring 2016 Assignment 5 Logic Programming Submission instructions: a. Submit an archive file named id1_id2.zip where id1 and id2 are the IDs of the students responsible

More information

Type Systems. Seman&cs. CMPT 379: Compilers Instructor: Anoop Sarkar. anoopsarkar.github.io/compilers-class

Type Systems. Seman&cs. CMPT 379: Compilers Instructor: Anoop Sarkar. anoopsarkar.github.io/compilers-class Type Systems Seman&cs CMPT 379: Compilers Instructor: Anoop Sarkar anoopsarkar.github.io/compilers-class 1 Equality of types Main seman&c tasks involve liveness analysis and checking equality Equality

More information

Lecture Outline. COOL operational semantics. Operational Semantics of Cool. Motivation. Lecture 13. Notation. The rules. Evaluation Rules So Far

Lecture Outline. COOL operational semantics. Operational Semantics of Cool. Motivation. Lecture 13. Notation. The rules. Evaluation Rules So Far Lecture Outline Operational Semantics of Cool Lecture 13 COOL operational semantics Motivation Notation The rules Prof. Aiken CS 143 Lecture 13 1 Prof. Aiken CS 143 Lecture 13 2 Motivation We must specify

More information

Higher-Order Logic. Specification and Verification with Higher-Order Logic

Higher-Order Logic. Specification and Verification with Higher-Order Logic Higher-Order Logic Specification and Verification with Higher-Order Logic Arnd Poetzsch-Heffter (Slides by Jens Brandt) Software Technology Group Fachbereich Informatik Technische Universität Kaiserslautern

More information

An introduction to Scheme

An introduction to Scheme An introduction to Scheme Introduction A powerful programming language is more than just a means for instructing a computer to perform tasks. The language also serves as a framework within which we organize

More information

Exercise 1 (2+2+2 points)

Exercise 1 (2+2+2 points) 1 Exercise 1 (2+2+2 points) The following data structure represents binary trees only containing values in the inner nodes: data Tree a = Leaf Node (Tree a) a (Tree a) 1 Consider the tree t of integers

More information

Formal Systems and their Applications

Formal Systems and their Applications Formal Systems and their Applications Dave Clarke (Dave.Clarke@cs.kuleuven.be) Acknowledgment: these slides are based in part on slides from Benjamin Pierce and Frank Piessens 1 Course Overview Introduction

More information

Type Systems COMP 311 Rice University Houston, Texas

Type Systems COMP 311 Rice University Houston, Texas Rice University Houston, Texas 1 Type Systems for Programming Language were invented by mathematicians before electronic computers were invented. What is a type? A meaningful subset of the set of the domain

More information

Logic Programming: Lecture 1

Logic Programming: Lecture 1 Logic Programming: Lecture 1 Madhavan Mukund Chennai Mathematical Institute madhavan@cmi.ac.in PLC, 3 April 2017 Logic programming Programming with relations Variables Names starting with a capital letter

More information

Type Inference Systems. Type Judgments. Deriving a Type Judgment. Deriving a Judgment. Hypothetical Type Judgments CS412/CS413

Type Inference Systems. Type Judgments. Deriving a Type Judgment. Deriving a Judgment. Hypothetical Type Judgments CS412/CS413 Type Inference Systems CS412/CS413 Introduction to Compilers Tim Teitelbaum Type inference systems define types for all legal programs in a language Type inference systems are to type-checking: As regular

More information

Lambda Calculus and Type Inference

Lambda Calculus and Type Inference Lambda Calculus and Type Inference Björn Lisper Dept. of Computer Science and Engineering Mälardalen University bjorn.lisper@mdh.se http://www.idt.mdh.se/ blr/ October 13, 2004 Lambda Calculus and Type

More information

INCREMENTAL SOFTWARE CONSTRUCTION WITH REFINEMENT DIAGRAMS

INCREMENTAL SOFTWARE CONSTRUCTION WITH REFINEMENT DIAGRAMS INCREMENTAL SOFTWARE CONSTRUCTION WITH REFINEMENT DIAGRAMS Ralph-Johan Back Abo Akademi University July 6, 2006 Home page: www.abo.fi/~backrj Research / Current research / Incremental Software Construction

More information

Comp 311: Sample Midterm Examination

Comp 311: Sample Midterm Examination Comp 311: Sample Midterm Examination October 29, 2007 Name: Id #: Instructions 1. The examination is closed book. If you forget the name for a Scheme operation, make up a name for it and write a brief

More information

1.3. Conditional expressions To express case distinctions like

1.3. Conditional expressions To express case distinctions like Introduction Much of the theory developed in the underlying course Logic II can be implemented in a proof assistant. In the present setting this is interesting, since we can then machine extract from a

More information

Quick announcement. Midterm date is Wednesday Oct 24, 11-12pm.

Quick announcement. Midterm date is Wednesday Oct 24, 11-12pm. Quick announcement Midterm date is Wednesday Oct 24, 11-12pm. The lambda calculus = ID (λ ID. ) ( ) The lambda calculus (Racket) = ID (lambda (ID) ) ( )

More information

The semantics of a programming language is concerned with the meaning of programs, that is, how programs behave when executed on computers.

The semantics of a programming language is concerned with the meaning of programs, that is, how programs behave when executed on computers. Semantics The semantics of a programming language is concerned with the meaning of programs, that is, how programs behave when executed on computers. The semantics of a programming language assigns a precise

More information

CMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics

CMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics Recall Architecture of Compilers, Interpreters CMSC 330: Organization of Programming Languages Source Scanner Parser Static Analyzer Operational Semantics Intermediate Representation Front End Back End

More information

Types. Type checking. Why Do We Need Type Systems? Types and Operations. What is a type? Consensus

Types. Type checking. Why Do We Need Type Systems? Types and Operations. What is a type? Consensus Types Type checking What is a type? The notion varies from language to language Consensus A set of values A set of operations on those values Classes are one instantiation of the modern notion of type

More information

Typed Scheme: Scheme with Static Types

Typed Scheme: Scheme with Static Types Typed Scheme: Scheme with Static Types Version 4.1.1 Sam Tobin-Hochstadt October 5, 2008 Typed Scheme is a Scheme-like language, with a type system that supports common Scheme programming idioms. Explicit

More information

Exercise 1 ( = 24 points)

Exercise 1 ( = 24 points) 1 Exercise 1 (4 + 5 + 4 + 6 + 5 = 24 points) The following data structure represents polymorphic binary trees that contain values only in special Value nodes that have a single successor: data Tree a =

More information

11/6/17. Functional programming. FP Foundations, Scheme (2) LISP Data Types. LISP Data Types. LISP Data Types. Scheme. LISP: John McCarthy 1958 MIT

11/6/17. Functional programming. FP Foundations, Scheme (2) LISP Data Types. LISP Data Types. LISP Data Types. Scheme. LISP: John McCarthy 1958 MIT Functional programming FP Foundations, Scheme (2 In Text: Chapter 15 LISP: John McCarthy 1958 MIT List Processing => Symbolic Manipulation First functional programming language Every version after the

More information

Operational Semantics of Cool

Operational Semantics of Cool Operational Semantics of Cool Lecture 22 Dr. Sean Peisert ECS 142 Spring 2009 1 Status Project 3 due on Friday Project 4 assigned on Friday. Due June 5, 11:55pm Office Hours this week are Wed at 4pm and

More information

Milawa an extensible proof checker

Milawa an extensible proof checker Milawa an extensible proof checker Jared Davis ACL2 Seminar, November 16, 2005 Outline The Milawa logic A primitive proof checker An extended proof checker Soundness of the extended checker A reflection

More information

Application: Programming Language Semantics

Application: Programming Language Semantics Chapter 8 Application: Programming Language Semantics Prof. Dr. K. Madlener: Specification and Verification in Higher Order Logic 527 Introduction to Programming Language Semantics Programming Language

More information

The Formal Semantics of Programming Languages An Introduction. Glynn Winskel. The MIT Press Cambridge, Massachusetts London, England

The Formal Semantics of Programming Languages An Introduction. Glynn Winskel. The MIT Press Cambridge, Massachusetts London, England The Formal Semantics of Programming Languages An Introduction Glynn Winskel The MIT Press Cambridge, Massachusetts London, England Series foreword Preface xiii xv 1 Basic set theory 1 1.1 Logical notation

More information

Lambda Calculus and Type Inference

Lambda Calculus and Type Inference Lambda Calculus and Type Inference Björn Lisper Dept. of Computer Science and Engineering Mälardalen University bjorn.lisper@mdh.se http://www.idt.mdh.se/ blr/ August 17, 2007 Lambda Calculus and Type

More information

c constructor P, Q terms used as propositions G, H hypotheses scope identifier for a notation scope M, module identifiers t, u arbitrary terms

c constructor P, Q terms used as propositions G, H hypotheses scope identifier for a notation scope M, module identifiers t, u arbitrary terms Coq quick reference Meta variables Usage Meta variables Usage c constructor P, Q terms used as propositions db identifier for a hint database s string G, H hypotheses scope identifier for a notation scope

More information

Coq quick reference. Category Example Description. Inductive type with instances defined by constructors, including y of type Y. Inductive X : Univ :=

Coq quick reference. Category Example Description. Inductive type with instances defined by constructors, including y of type Y. Inductive X : Univ := Coq quick reference Category Example Description Meta variables Usage Meta variables Usage c constructor P, Q terms used as propositions db identifier for a hint database s string G, H hypotheses scope

More information

Software Paradigms (Lesson 4) Functional Programming Paradigm

Software Paradigms (Lesson 4) Functional Programming Paradigm Software Paradigms (Lesson 4) Functional Programming Paradigm Table of Contents 1 Introduction... 2 2 Evaluation of Functions... 3 3 Compositional (Construct) Operators... 4 4 Some Implementation Issues...

More information

== is a decent equivalence

== is a decent equivalence Table of standard equiences 30/57 372 TABLES FOR PART I Propositional Logic Lecture 2 (Chapter 7) September 9, 2016 Equiences for connectives Commutativity: Associativity: P Q == Q P, (P Q) R == P (Q R),

More information

Operational Semantics of Cool

Operational Semantics of Cool Operational Semantics of Cool Key Concepts semantics: the meaning of a program, what does program do? how the code is executed? operational semantics: high level code generation steps of calculating values

More information

Programming Languages Fall 2014

Programming Languages Fall 2014 Programming Languages Fall 2014 Lecture 7: Simple Types and Simply-Typed Lambda Calculus Prof. Liang Huang huang@qc.cs.cuny.edu 1 Types stuck terms? how to fix it? 2 Plan First I For today, we ll go back

More information

Functions. Nate Foster Spring 2018

Functions. Nate Foster Spring 2018 Functions Nate Foster Spring 2018 A0: Warmup Worth only 1% of final grade; other assignments will be 5% much easier coding problems intended to give you low-stakes experience with 3110 workflow Please

More information

CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer Science (Arkoudas and Musser) Chapter p. 1/27

CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer Science (Arkoudas and Musser) Chapter p. 1/27 CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer Science (Arkoudas and Musser) Chapter 2.1-2.7 p. 1/27 CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer

More information

Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Chapter 6 Outline. Unary Relational Operations: SELECT and

Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Chapter 6 Outline. Unary Relational Operations: SELECT and Chapter 6 The Relational Algebra and Relational Calculus Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 6 Outline Unary Relational Operations: SELECT and PROJECT Relational

More information

Overloading, Type Classes, and Algebraic Datatypes

Overloading, Type Classes, and Algebraic Datatypes Overloading, Type Classes, and Algebraic Datatypes Delivered by Michael Pellauer Arvind Computer Science and Artificial Intelligence Laboratory M.I.T. September 28, 2006 September 28, 2006 http://www.csg.csail.mit.edu/6.827

More information

Lecture 7. Search. Search. Foundations of Constraint Programming

Lecture 7. Search. Search. Foundations of Constraint Programming Lecture 7 1 Outline Introduce search trees Discuss various types of labeling trees, in particular trees for - forward checking - partial look ahead - maintaining arc consistency (MAC) Discuss various search

More information

Calculus of Inductive Constructions

Calculus of Inductive Constructions Calculus of Inductive Constructions Software Formal Verification Maria João Frade Departmento de Informática Universidade do Minho 2008/2009 Maria João Frade (DI-UM) Calculus of Inductive Constructions

More information

CS 671, Automated Reasoning

CS 671, Automated Reasoning CS 671, Automated Reasoning Lesson 20: Type Constructs based on Intersection (II): dependent records, abstract data types, basic algebra April 3, 2001 Last time we discussed record types and their representation

More information

CIS 500 Software Foundations Midterm I

CIS 500 Software Foundations Midterm I CIS 500 Software Foundations Midterm I October 11, 2006 Name: Student ID: Email: Status: Section: registered for the course not registered: sitting in to improve a previous grade not registered: just taking

More information

Polymorphic lambda calculus Princ. of Progr. Languages (and Extended ) The University of Birmingham. c Uday Reddy

Polymorphic lambda calculus Princ. of Progr. Languages (and Extended ) The University of Birmingham. c Uday Reddy 06-02552 Princ. of Progr. Languages (and Extended ) The University of Birmingham Spring Semester 2016-17 School of Computer Science c Uday Reddy2016-17 Handout 6: Polymorphic Type Systems 1. Polymorphic

More information

Operational Semantics. One-Slide Summary. Lecture Outline

Operational Semantics. One-Slide Summary. Lecture Outline Operational Semantics #1 One-Slide Summary Operational semantics are a precise way of specifying how to evaluate a program. A formal semantics tells you what each expression means. Meaning depends on context:

More information

Introduction to OCaml

Introduction to OCaml Fall 2018 Introduction to OCaml Yu Zhang Course web site: http://staff.ustc.edu.cn/~yuzhang/tpl References Learn X in Y Minutes Ocaml Real World OCaml Cornell CS 3110 Spring 2018 Data Structures and Functional

More information

Lecture Outline. COOL operational semantics. Operational Semantics of Cool. Motivation. Notation. The rules. Evaluation Rules So Far.

Lecture Outline. COOL operational semantics. Operational Semantics of Cool. Motivation. Notation. The rules. Evaluation Rules So Far. Lecture Outline Operational Semantics of Cool COOL operational semantics Motivation Adapted from Lectures by Profs. Alex Aiken and George Necula (UCB) Notation The rules CS781(Prasad) L24CG 1 CS781(Prasad)

More information

Exercise 1 ( = 18 points)

Exercise 1 ( = 18 points) 1 Exercise 1 (4 + 5 + 4 + 5 = 18 points) The following data structure represents polymorphic binary trees that contain values only in special Value nodes that have a single successor: data Tree a = Leaf

More information

Foundations of AI. 9. Predicate Logic. Syntax and Semantics, Normal Forms, Herbrand Expansion, Resolution

Foundations of AI. 9. Predicate Logic. Syntax and Semantics, Normal Forms, Herbrand Expansion, Resolution Foundations of AI 9. Predicate Logic Syntax and Semantics, Normal Forms, Herbrand Expansion, Resolution Wolfram Burgard, Andreas Karwath, Bernhard Nebel, and Martin Riedmiller 09/1 Contents Motivation

More information

The Typed λ Calculus and Type Inferencing in ML

The Typed λ Calculus and Type Inferencing in ML Notes on Types S. Arun-Kumar Department of Computer Science and Engineering Indian Institute of Technology New Delhi, 110016 email: sak@cse.iitd.ernet.in April 14, 2002 2 Chapter 1 The Typed λ Calculus

More information

Software Properties as Axioms and Theorems

Software Properties as Axioms and Theorems Applied Software Properties as Axioms and Theorems proofs by induction or How to Write Reliable Software and know it's reliable Applied 1 Example: Multiplexor Function Problem: Multiplex two sequences

More information

COP4020 Programming Languages. Functional Programming Prof. Robert van Engelen

COP4020 Programming Languages. Functional Programming Prof. Robert van Engelen COP4020 Programming Languages Functional Programming Prof. Robert van Engelen Overview What is functional programming? Historical origins of functional programming Functional programming today Concepts

More information

3 No-Wait Job Shops with Variable Processing Times

3 No-Wait Job Shops with Variable Processing Times 3 No-Wait Job Shops with Variable Processing Times In this chapter we assume that, on top of the classical no-wait job shop setting, we are given a set of processing times for each operation. We may select

More information

Idris: Implementing a Dependently Typed Programming Language

Idris: Implementing a Dependently Typed Programming Language Idris: Implementing a Dependently Typed Programming Language Edwin Brady University of St Andrews ecb10@st-andrews.ac.uk @edwinbrady Type Inference and Automated Proving, Dundee, 12th May 2015 1 / 25 Idris

More information

Quasilinear First-Order PDEs

Quasilinear First-Order PDEs MODULE 2: FIRST-ORDER PARTIAL DIFFERENTIAL EQUATIONS 16 Lecture 3 Quasilinear First-Order PDEs A first order quasilinear PDE is of the form a(x, y, z) + b(x, y, z) x y = c(x, y, z). (1) Such equations

More information

Contents. Chapter 1 SPECIFYING SYNTAX 1

Contents. Chapter 1 SPECIFYING SYNTAX 1 Contents Chapter 1 SPECIFYING SYNTAX 1 1.1 GRAMMARS AND BNF 2 Context-Free Grammars 4 Context-Sensitive Grammars 8 Exercises 8 1.2 THE PROGRAMMING LANGUAGE WREN 10 Ambiguity 12 Context Constraints in Wren

More information

Evaluation Trees for Proposition Algebra

Evaluation Trees for Proposition Algebra Evaluation Trees for Proposition Algebra Alban Ponse joined work with Jan A. Bergstra section Theory of Computer Science Informatics Institute, University of Amsterdam https://staff.fnwi.uva.nl/a.ponse/

More information

VS 3 : SMT Solvers for Program Verification

VS 3 : SMT Solvers for Program Verification VS 3 : SMT Solvers for Program Verification Saurabh Srivastava 1,, Sumit Gulwani 2, and Jeffrey S. Foster 1 1 University of Maryland, College Park, {saurabhs,jfoster}@cs.umd.edu 2 Microsoft Research, Redmond,

More information

Type Inference: Constraint Generation

Type Inference: Constraint Generation Type Inference: Constraint Generation sk and dbtucker 2002-11-11 1 Inferring Types We ve seen the value of having explicit polymorphism in our language it lets us write programs that work on may different

More information

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages Harvard School of Engineering and Applied Sciences CS 152: Programming Languages Lecture 19 Tuesday, April 3, 2018 1 Introduction to axiomatic semantics The idea in axiomatic semantics is to give specifications

More information

Fall Lecture 3 September 4. Stephen Brookes

Fall Lecture 3 September 4. Stephen Brookes 15-150 Fall 2018 Lecture 3 September 4 Stephen Brookes Today A brief remark about equality types Using patterns Specifying what a function does equality in ML e1 = e2 Only for expressions whose type is

More information

CS 314 Principles of Programming Languages. Lecture 16

CS 314 Principles of Programming Languages. Lecture 16 CS 314 Principles of Programming Languages Lecture 16 Zheng Zhang Department of Computer Science Rutgers University Friday 28 th October, 2016 Zheng Zhang 1 CS@Rutgers University Class Information Reminder:

More information

6. Hoare Logic and Weakest Preconditions

6. Hoare Logic and Weakest Preconditions 6. Hoare Logic and Weakest Preconditions Program Verification ETH Zurich, Spring Semester 07 Alexander J. Summers 30 Program Correctness There are many notions of correctness properties for a given program

More information

Lecture 15 CIS 341: COMPILERS

Lecture 15 CIS 341: COMPILERS Lecture 15 CIS 341: COMPILERS Announcements HW4: OAT v. 1.0 Parsing & basic code generation Due: March 28 th No lecture on Thursday, March 22 Dr. Z will be away Zdancewic CIS 341: Compilers 2 Adding Integers

More information

6.821 Programming Languages Handout Fall MASSACHVSETTS INSTITVTE OF TECHNOLOGY Department of Electrical Engineering and Compvter Science

6.821 Programming Languages Handout Fall MASSACHVSETTS INSTITVTE OF TECHNOLOGY Department of Electrical Engineering and Compvter Science 6.821 Programming Languages Handout Fall 2002 MASSACHVSETTS INSTITVTE OF TECHNOLOGY Department of Electrical Engineering and Compvter Science Problem Set 6 Problem 1: cellof Subtyping Do exercise 11.6

More information

CS 440: Programming Languages and Translators, Spring 2019 Mon

CS 440: Programming Languages and Translators, Spring 2019 Mon Haskell, Part 4 CS 440: Programming Languages and Translators, Spring 2019 Mon 2019-01-28 More Haskell Review definition by cases Chapter 6: Higher-order functions Revisit currying map, filter Unnamed

More information

CS153: Compilers Lecture 14: Type Checking

CS153: Compilers Lecture 14: Type Checking CS153: Compilers Lecture 14: Type Checking Stephen Chong https://www.seas.harvard.edu/courses/cs153 Announcements Project 4 out Due Thursday Oct 25 (7 days) Project 5 out Due Tuesday Nov 13 (26 days) Project

More information

Dependent Object Types - A foundation for Scala's type system

Dependent Object Types - A foundation for Scala's type system Dependent Object Types - A foundation for Scala's type system Draft of January 14, 2010 Do Not Distrubute Martin Odersky, Georey Alan Washburn EPFL Abstract. 1 Introduction This paper presents a proposal

More information

CSE 341: Programming Languages

CSE 341: Programming Languages CSE 341: Programming Languages Autumn 2005 Lecture 10 Mutual Recursion, Equivalence, and Syntactic Sugar CSE 341 Autumn 2005, Lecture 10 1 Mutual Recursion You ve already seen how multiple functions can

More information

Lambda Calculus. Type Systems, Lectures 3. Jevgeni Kabanov Tartu,

Lambda Calculus. Type Systems, Lectures 3. Jevgeni Kabanov Tartu, Lambda Calculus Type Systems, Lectures 3 Jevgeni Kabanov Tartu, 13.02.2006 PREVIOUSLY ON TYPE SYSTEMS Arithmetical expressions and Booleans Evaluation semantics Normal forms & Values Getting stuck Safety

More information

Chapter 3 (part 3) Describing Syntax and Semantics

Chapter 3 (part 3) Describing Syntax and Semantics Chapter 3 (part 3) Describing Syntax and Semantics Chapter 3 Topics Introduction The General Problem of Describing Syntax Formal Methods of Describing Syntax Attribute Grammars Describing the Meanings

More information

02157 Functional Programming. Michael R. Ha. Lecture 2: Functions, Types and Lists. Michael R. Hansen

02157 Functional Programming. Michael R. Ha. Lecture 2: Functions, Types and Lists. Michael R. Hansen Lecture 2: Functions, Types and Lists nsen 1 DTU Compute, Technical University of Denmark Lecture 2: Functions, Types and Lists MRH 13/09/2018 Outline Functions as first-class citizens Types, polymorphism

More information

CS 457/557: Functional Languages

CS 457/557: Functional Languages CS 457/557: Functional Languages Lists and Algebraic Datatypes Mark P Jones Portland State University 1 Why Lists? Lists are a heavily used data structure in many functional programs Special syntax is

More information

Type Declarations. [... <id> τ... ] <id> : τ. Γ <num> : number. Γ true : boolean. Γ false : boolean. Γ e 1 : number.

Type Declarations. [... <id> τ... ] <id> : τ. Γ <num> : number. Γ true : boolean. Γ false : boolean. Γ e 1 : number. Type Inference 1 Type Declarations Γ : number Γ true : boolean Γ e 1 : number [... τ... ] : τ Γ false : boolean Γ e 2 : number Γ {+ e 1 e 2 } : number Γ e 1 : boolean Γ e 2 : τ 0 Γ e 3

More information

From the λ-calculus to Functional Programming Drew McDermott Posted

From the λ-calculus to Functional Programming Drew McDermott Posted From the λ-calculus to Functional Programming Drew McDermott drew.mcdermott@yale.edu 2015-09-28 Posted 2015-10-24 The λ-calculus was intended from its inception as a model of computation. It was used by

More information

Induction for Data Types

Induction for Data Types Induction for Data Types COMP1600 / COMP6260 Dirk Pattinson Australian National University Semester 2, 2017 Catch Up / Drop in Lab When Fridays, 15.00-17.00 Where N335, CSIT Building (bldg 108) Until the

More information

Programming Language Concepts: Lecture 22

Programming Language Concepts: Lecture 22 Programming Language Concepts: Lecture 22 Madhavan Mukund Chennai Mathematical Institute madhavan@cmi.ac.in http://www.cmi.ac.in/~madhavan/courses/pl2009 PLC 2009, Lecture 22, 15 April 2009 Logic programming

More information

Com S 541. Programming Languages I

Com S 541. Programming Languages I Programming Languages I Lecturer: TA: Markus Lumpe Department of Computer Science 113 Atanasoff Hall http://www.cs.iastate.edu/~lumpe/coms541.html TR 12:40-2, W 5 Pramod Bhanu Rama Rao Office hours: TR

More information

Functional Logic Programming. Kristjan Vedel

Functional Logic Programming. Kristjan Vedel Functional Logic Programming Kristjan Vedel Imperative vs Declarative Algorithm = Logic + Control Imperative How? Explicit Control Sequences of commands for the computer to execute Declarative What? Implicit

More information

MIDTERM EXAMINATION - CS130 - Spring 2005

MIDTERM EXAMINATION - CS130 - Spring 2005 MIDTERM EAMINATION - CS130 - Spring 2005 Your full name: Your UCSD ID number: This exam is closed book and closed notes Total number of points in this exam: 231 + 25 extra credit This exam counts for 25%

More information

Chapter 15 Functional Programming Languages

Chapter 15 Functional Programming Languages Chapter 15 Functional Programming Languages Fundamentals of Functional Programming Languages Introduction to Scheme A programming paradigm treats computation as the evaluation of mathematical functions.

More information

CIS 500 Software Foundations. Final Exam. May 3, Answer key

CIS 500 Software Foundations. Final Exam. May 3, Answer key CIS 500 Software Foundations Final Exam May 3, 2012 Answer key This exam includes material on the Imp language and the simply-typed lambda calculus. Some of the key definitions are repeated, for easy reference,

More information

Chapter 1. Fundamentals of Higher Order Programming

Chapter 1. Fundamentals of Higher Order Programming Chapter 1 Fundamentals of Higher Order Programming 1 The Elements of Programming Any powerful language features: so does Scheme primitive data procedures combinations abstraction We will see that Scheme

More information

CS558 Programming Languages

CS558 Programming Languages CS558 Programming Languages Fall 2016 Lecture 7a Andrew Tolmach Portland State University 1994-2016 Values and Types We divide the universe of values according to types A type is a set of values and a

More information

CSC173 Lambda Calculus Lambda Calculus Evaluation (10 min) Evaluate this expression (β-reduce with normal-order evaluation):

CSC173 Lambda Calculus Lambda Calculus Evaluation (10 min) Evaluate this expression (β-reduce with normal-order evaluation): CSC173 Lambda Calculus 014 Please write your name on the bluebook. You may use two sides of handwritten notes. There are 90 possible points and 75 is a perfect score. Stay cool and please write neatly.

More information

Operational Semantics

Operational Semantics Operational Semantics #1 One-Slide Summary Operational semantics is a precise way of specifying how to evaluate a program. A formal semantics tells you what each expression means. Meaning depends on context:

More information